Summary

• A discovery scan that finds zero tools is currently silent — from the backend/Sentry you cannot tell apart an errored scan, a missed detection (tool present, not detected), and a genuinely empty device; nor, for the empty case, an enumeration miss (no human user found) from a timing race (binaries not on disk yet).
• This emits one fire-and-forget Sentry event (phase=no_tools_found) on the no-tools path, carrying the discriminators needed to diagnose it at a glance.

Why homes_enumerated is the key field

The existing metrics report user_count = len(all_users) after the if not all_users: all_users = [get_user_info()] fallback, so a true enumeration miss (0) is masked as 1. We capture the count before the fallback: homes_enumerated == 0 ⇒ enumeration miss (the macOS/AD network-account class); > 0 ⇒ genuinely empty / timing race.

Changes

• scripts/coding_discovery_tools/ai_tools_discovery.py
  • Capture homes_enumerated before the user-enumeration fallback.
  • On if not tools:, emit report_to_sentry(RuntimeError("Discovery found no tools"), level="warning") with context: phase, homes_enumerated, users_scanned, used_fallback_user, is_root (when os.getuid exists), os, duration_ms (plus device_id/run_id/system_user from the existing sentry_ctx).
• tests/test_discovery_flow.py
  • New TestNoToolsSentryEvent: fires exactly once on a zero-tool scan with the right fields; does not fire when tools are found.

Diagnosing from Sentry

Filter phase:no_tools_found, then read per event:

• homes_enumerated:0 → enumeration miss (network/AD account dropped)
• homes_enumerated:>0 → genuinely empty disk at scan time (timing race / true-empty)
• is_root:true → ran in MDM/SYSTEM context

Constraints honored

• Fire-and-forget — wrapped in try/except: pass; telemetry can never raise into or slow the scan.
• Curl-only — reuses the existing report_to_sentry (no new network code; no urllib).
• No PII — counts and booleans only; no username lists or home-dir contents.
• Fires only when tools == []; relies on report_to_sentry's existing per-run cap + dedup (unique phase) + circuit breaker.

Known limitation (deliberate, minimal scope)

Discriminator fields land in Sentry extra, not searchable tags — only phase:no_tools_found is filterable; values are readable per-event but not facetable/alertable without a follow-up _SENTRY_TAG_KEYS addition. No backend/DeviceScan/migration changes (intentionally out of scope).

Test plan

• python3 -m pytest tests/test_discovery_flow.py -v — new tests pass
• Full tests/ suite green (69 passed), no regressions
• Both changed files byte-compile clean

🤖 Generated with Claude Code

Greptile Summary

This PR adds Sentry visibility for discovery scans that find no tools. The main changes are:

• Adds pre-fallback home enumeration counts to the discovery flow.
• Sends one priority no_tools_found warning with scan context when no tools are detected.
• Lets priority Sentry events bypass the per-run cap and circuit breaker while keeping deduplication.
• Adds tests for the no-tools event and priority Sentry behavior.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

_{Reviews (3): Last reviewed commit: "Let priority Sentry events bypass the ci..." | Re-trigger Greptile}